Security Risks of Java Cards

As early as the 1980s, France issued smart cards for their Public Telephone and Telegraph (PTT) system. Only recently have smart cards begun penetrating the commercial market in North America. With the introduction of Java Card 2.0 (hereafter referred to simply as Java Card), interest in smart cards for commercial applications in North America appears certain to grow. The key innovation that Java Card brings to smart cards is the ability now for programmers anywhere to write programs that will drive smart card applications. Previously, programming smart cards was the exclusive sanctuary of a small group of assembly language programmers that coded at the machine architecture level. With adoption of the Java Card subset of Java, smart card applications can be developed by a broad range of programmers using a variety of development environments. Commensurate with innovation in smart card technology is the potential for new, serious violations of security in using these cards. For example, smart cards that hold stored value must not be susceptible to attacks that can add value arbitrarily to the card without deducting an identical amount from another account. Incorporating a sophisticated operating system on a smart card also introduces the possibility that errors in the implementation may be exploited by malicious programs to subvert the card security. The rocky history of Java security has shown that even though security control mechanisms were built into the Java Virtual Machine (JVM), the complexity of the machine made an error-free implementation impossible. Some of these aws were exploited to break the security of the JVM [6]. Java Card is a stripped down version of the Java language that is designed for the smaller memory footprint of smart cards. For instance, Java Card does not support threading, and optionally may not support garbage collection and de-allocation of memory. The Java Card subset has its disadvantages as well as its advantages in relation to security. On the one hand, the security manager class is not included in the Java Card. In standard Java, the security manager is responsible for denying unsafe operations. On the other hand, dynamic class loading is not supported for Java Card. This means that an applet cannot dynamically download classes that are not already existent on the card. Dynamic class loading is a key source of insecurity in Java; omitting it from Java Card goes a long way to mitigate the type confusion attacks that have plagued Java security to date [6]. In this article, an overview of the security issues in smart cards is presented to identify potential risk areas that must be assessed prior to elding Java-enabled smart cards in commercial applications. The di erent risk areas this paper covers are: secure protocols for electronic transactions, protocol interactions, risks of multi-application cards, the risks of an immature technology deployed in critical applications, and physical security considerations.